coverage: 100.0%. remained the same when pulling 8c896a7 on jitsedesmet:refactor/remove-ordering-redundency into 6c22f37 on comunica:master.

@rubensworks given the implementation in #180 is what you want for Ordering, I would keep making the regular functions call the regular functions since it is more self-contained.
Also, if we would want to call ordering, we would not want the fall through case as mentioned in a commend I made (and later resolved in favor of this PR)

Also, if we would want to call ordering, we would not want the fall through case as mentioned in #180 (comment)

Ok, then we can change that I guess? That's the same reason why I added the strict parameter on orderTypes in d1e01c3.

But why would you want this? I feel like this case is way better? You have all the logic of the regularfunctions in this one file?
Why would you want to go: RegularFunction -> Ordering -> RegularFunction when you can do RegularFunction -> RegularFunction?

But why would you want this? I feel like this case is way better? You have all the logic of the regularfunctions in this one file?
Why would you want to go: RegularFunction -> Ordering -> RegularFunction when you can do RegularFunction -> RegularFunction?

Not sure I understand you correctly.
What I suggest is to just delegate to the orderTypes function. AFAIK, orderTypes has no external references back to regular functions.

I just looked again at #180, and now I understand your comment, because you did add a back-reference to regular functions from type ordering there.

Closes #178